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--FIELD OF INVENTION— 

The present invention relates to a method of compacting a pro grammepro eram of the 
intermediate object code type, which can be run in an on-board system provided with data 
processing resources, and to the corresponding compaction method. 



--BACKGROUND OF THE INVENTION— 

These days, on-board systems provided with data processing resources enable 
increasingly complex and larger numbers of functions to be performed because the hardware 
used for these portable objects and their software, or more specifically the application 
pro gram m epro gram s embedded in the latter as a means of enabling them to run one or more 
specific functions, are constantly being optimised. The concept of on-board system covers any 
portable computer system, such as a portable object, microprocessor card or similar, as opposed 
to a conventional microcomputer. 

This is particularly so in the case of microprocessor cards, also known as chip cards, such 
as that illustrated in figure la, used in conjunction with a compiler to generate instructions and 
an interpreter which enables these instructions to be run by the microprocessor, as illustrated in 
figure lb. Conventionally, as illustrated in figure la, a microprocessor card 10 comprises an 
input/output system 12 linked to the microprocessor 14, a RAM memory 16, a non-volatile 
memory 18 comprising a read only ROM memory 18b and a programmable memory 18a. All of 
these elements are linked to the microprocessor 14 by a BUS line. A data encryption/decryption 
module 20 may be provided, as required. 
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Figure lc illustrates all the application software elements, such as electronic purse, 
electronic commerce or health, embedded in the non-volatile programmable memory, the 
interpreter in a non-volatile programmable memory or a read only memory and the operating 
system in a read only memory ROM. 

The intermediate object code is generated by the compiler from a source 
pro gramrnepro gram, usually written in high level language based on ASCII characters. The 
source pro eramme pro gram and the corresponding intermediate object code may be run by all the 
standard microprocessors because the interpreter ensures that the standard instructions of the 
intermediate object code are translated, in software terms, into instructions that can be directly 
executed by the microprocessor. 

By way of example, although this is not restrictive, microprocessor card manufacturers 
have recently developed interpreters embedded in the read only memory ROM. This type of 
interpreter reads in sequence a pro eramm epro gram or intermediate object code, supporting an 
application for example, which is loaded into the programmable memory of the microprocessor 
card, for example. Each standard instruction of this intermediate object code is interpreted by the 
interpreter, then run by the microprocessor. As a general rule, the standard instructions of the 
intermediate object code enable changing functions to be processed, such as arithmetic 
processing and object manipulation. The object concept relates to computed objects such as lists, 
data tables or similar. 

However, due in particular to the fact that these microprocessor cards are portable in 
nature, the size and space occupied by the latter are limited. The same applies to the size of their 
programmable memory, which is limited, by construction, to several kilobytes. This structural 
limitation makes it impossible to run large application pro ^ramm epro gram s . 

Furthermore, the current tendency to use multi-application on-board systems is faced 
with the recurring problem caused by the fact that the number of applications installed on a same 
on-board system or microprocessor card rarely exceeds three applications. 
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— OBJECTS OF THE INVENTION- 

The objective of this invention is to overcome the disadvantage outlined above by 
running a method for compacting a pro gramm ep ro gram of the intermediate object code type, 
which can be used in an on-board system of the microprocessor type in order to free up memory 
space in the programmable memory of this on-board system, thereby enabling at least one 
additional application to be embedded once the latter has been compacted. 

Another objective of this invention is to implement a system of compacting 
pro gramm ep ro gram s of the intermediate object code type which will allow a pro gramm e pro gram 
of the compacted intermediate object code type to be embedded in a multi-application, on-board 
system having data processing resources that will allow compacted programm e program s of the 
intermediate object type to be run without significantly altering the running time and to do so in 
total transparency with regard to the process inherent in each non-compacted application. 

— SUMMARY OF THE INVENTION- 

The method of compacting a pro gramm e pro gram of the intermediate object type 
proposed by the invention, which consists of a sequence of standard instructions, this on-board 
system being provided with a memory and a pro gramm epro gram language interpreter capable of 
turning intermediate object code into instructions of an object code that can be run directly by a 
microprocessor and this pro gramm e pro gram normally being stored in the memory of this on- 
board system, is remarkable because the intermediate object code programm e program is 
searched in order to find identical sequences of successive standard instructions and the identical 
sequences of successive standard instructions are subjected to a comparison test to find a 
function, based on at least the number of occurrences of these sequences in the intermediate 
object code pro gramm e pro gram , that is higher than a reference value. If the above-mentioned 
test returns a positive response, a specific instruction is generated for each identical sequence of 
successive standard instructions which satisfies the test step, by defining a specific operating 
code and associating this specific operating code with the sequence of successive standard 
instructions. In addition, each occurrence of each sequence of standard successive instructions in 
the stored intermediate object code programrn e program is replaced by the specific operating 
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code associated with it to obtain a compacted intermediate object code programm e program . a 
series of standard instructions and specific operating codes. A decompression table is stored in 
the memory which enables a reciprocal link to be made between each specific operating code 
inserted and the sequence of successive standard instructions associated with the latter. This 
process enables the memory space occupied by the compacted intermediate object 
pro gramme pro gram to be optimised by storing only one occurrence of identical sequences of 
successive standard instructions in the programmable memory. 

The method, the system of compacting an intermediate object code pro gramm e pro pram 
and the corresponding multi-application on-board system proposed by this invention may be 
used in the technical field of on-board systems, more specifically for running and managing 
microprocessor cards. 

— BRIEF DESCRIPTION OF THE DRAWINGS— 

They will be more readily understood from the description below and the appended 
drawings, in which ? : 

- figure la illustrates microprocessor cards of prior art. 

- figure lb illustrates the conjunction of a com piler, an interpreter, and instructions to be 
run bv a microprocessor, according to prior art. 

- figure lc ill ustrates a pplication software elements of prior art apart from figur e s la to lc 
which illustrat e th e prior art , 

- figure 2a is a general flow chart illustrating a method of compacting an intermediate 
object code programme program as proposed by this invention; 

- figure 2b is a synoptic diagram illustrating how the different operators needed to obtain 
a compacted intermediate object code programm e program and parameters enabling this 
pro gramm e pro gram to be decompressed or executed, are applied; 
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- figure 2c, given purely as an illustration, shows this compacted intermediate object code 
proeramme program embedded in a programmable non- volatile memory of a microprocessor card 
and the parameters used to decompress and run the latter; 

- figure 3a is a diagram of one specific embodiment, although this is not restrictive, of the 
structure of a first file made up of the parameters for running or decompressing this intermediate 
object code proeramme program ; 

- figure 3b is a diagram showing one specific embodiment, although this is not restrictive, 
illustrating the structure of a second file made up of these parameters for running or 
decompressing this intermediate object code proeramm eprogram: 

- figure 4 shows, as an illustrative example, a compacted intermediate object code 
proeramm e program , as proposed by the invention, embedded in a non-volatile programmable 
memory of a microprocessor card or on-board multi-application system; 

- figure 5 shows an illustrative example of a specific method of compacting an 
intermediate object code programm e program in which specific codes, relating to separate 
applications or intermediate object code pro gramm e pro gram s, are updated; 

- figures 6a and 6b illustrate, in the form of functional elements, a system for compacting 
an intermediate object code programm e program as proposed by this invention. 

— MORE DETAILED DESCRIPTION- 

The method of compacting an intermediate object code pro gramm e pro gram as proposed 
by this invention will now be described with reference to figure 2a. The terms intermediate 
object code pro gramme pro gram cover any intermediate pro gramm e pro gram for the purpose of 
this patent application. 

This method will be described with reference to running an on-board system consisting of 
a microprocessor card of the type illustrated in figure la for example, although this example is 
not restrictive, this intermediate object code pro gramm e pro gram being obtained in a 



~CHGOl:30353016.vl 



5 



conventional manner, as illustrated in figure lb, a plurality of applications embedded in the 
programmable memory of the interpreter and the operating system OS in the ROM memory 
being illustrated in figure lc, although again this is not restrictive. 

The intermediate object code programme nrogram consists of a series of standard 
instructions which can be run by the microprocessor through the interpreter. 

The method of compacting a pro gramm e pro gram of this type consists in firstly 
embedding the latter in the programmable memory 18a, searching the intermediate object code 
pro gramm epro gram at a step 1000 as illustrated in figure 2a for identical sequences of successive 
standard instructions, these identical sequences being shown by Si. By identical sequences is 
meant a sequence of a given number n of octets likely to appear on a repetitive basis in the 
above-mentioned intermediate object code programme nrogram . Accordingly, the rank i of 
identical sequences indicates separate sequences for different values of i. Furthermore, the search 
step 1000 mentioned above consists in determining the number of occurrences Nj of each said 
identical sequence Sj. At the end of the search step 1000, a plurality of identical sequences Si will 
have been found, each sequence Si being separate, and a number Ni representing the number of 
occurrences of each of the sequences Si in the intermediate object code programm e program . 

After said step 1000, the compacting method proposed by the invention consists in 
subjecting, at a step 1001, the identical sequences of successive standard instructions Si to a 
comparison test of a function f(H) based on at least the number of occurrences Ni associated with 
an identical sequence Si. In figure 2a, the comparison test is written: 

f(Ni) > Ref. 

If the response to the test 1001 is negative, in which case the function of at least the 
number of occurrences Ni is not greater than the reference value, the test 1001 is applied to the 
next identical sequence, of rank i+1, the index i being incremented at step 1002. 

The steps 1000, 1001 and 1002 illustrated in figure 2a therefore enable a search to be run 
in the intermediate object code pro gramm e pro gram for identical sequences or series of octets or, 
at the very least, a given significant number of these identical sequences, as will be described 
farther on in the description. 
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If the response to said test 1001 is positive, the compacting method proposed by the 
invention then consists in generating a specific instruction, denoted by ISj, by defining a specific 
operating code, denoted by Q, and associating with this specific operating code the sequence of 
successive standard instructions which satisfied the test, this being the sequence of successive 
standard instructions Si. In figure 2a, the step by which specific instructions are set up is written: 

ISi = Q:Si. 

It should be pointed out that the step of defining a specific operating code and associating 
it with the sequence of successive standard instructions S\ may consist in assigning a code value 
and associating this code value with said sequence of instructions Si in the form of a list, for 
example. 

After step 1003, the compacting method then moves on to step 1004, at which each 
occurrence of the sequence of successive standard instructions Si in the intermediate object code 
pro gramm epro gram is replaced by the specific operating code Q which is associated with it in 
order to obtain a compacted object code programme program . denoted by FCC, which is a 
succession of standard instructions and specific operating codes Q. 

The replacement process can then be reiterated for each identical sequence or series of 
standard instructions Si as long as the index i is lower than a number P of identical sequences, 
whereby a comparison test 1005 of the index i with the value P will prompt a return to step 1002 
at which the index i described above is incremented whenever the response to this test is 
positive. 

In particular, it should be pointed out that by iterating the replacement process set up in 
this manner, a compacted object code pro gr amm epro gram will be obtained with which an 
execution file for the latter is associated, this file being denoted by FEX, the execution file 
consisting of at least one reciprocal match between each specific code Q and said sequence of 
successive standard instructions Si. 

Once the two above-mentioned files have been obtained, being the compacted 
intermediate object code pro gramm e pro gram and execution file, on a negative response to test 
1005 for example, a storage process can be initiated, whereby said intermediate object code 
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pro gramm e pro gram FCC obtained and of course the execution file FEX described above are 
stored in the programmable memory 18a, for example. Said storage may be in the non- volatile 
memory 18, programmable memory 18a or even in the read only memory 18b, although this is 
not restrictive. 

As far as said comparison test 1001 is concerned, it should be pointed out that the 
function of at least the number of occurrences of each identical sequence Si may be defined so as 
to optimise the gain in compression thus achieved. In one embodiment, which is not restrictive, 
this function may be set up so that a comparison is made between the size of each identical 
sequence of successive standard instructions and a threshold value, expressed as a number of 
standard instructions, for example. 

Figure 2b provides an illustrative example of an operating mode which allows a 
compacted intermediate object code pro gramme pro gram to be generated using the method 
proposed by the invention. 

During an initial stage, the creator of the intermediate object code pro gramm e pro gram 
sets up a text file containing the source programm e program . This pro gramm e pro gram , put 
together by the latter on the basis of an evolved language, is generally written in ASCII code so 
that it can be easily read and can contain comments to facilitate understanding on the one hand 
and development of the latter on the other. The source programme program thus created is 
inserted in a compiler of the conventional type, known as a standard compiler, the purpose of 
which is to transform each pro gramm e pro gram line into executable instructions or, at the very 
least, into instructions which can be interpreted in order to obtain an intermediate object code 
programm e program consisting of a standard sequence of instructions that can be interpreted by 
the interpreter. 

The intermediate object code file thus obtained after the compilation process is placed in 
a compression system allowing the compacting method to be run as described above with 
reference to figure 1. This compression system will be explained later in the description. 
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The compaction process applied and described above will then produce a file of 
interpretable instructions FCC, i.e. the file constituting the compacted intermediate object code 
programme program and the execution file FEX mentioned earlier in the description. 

The operating mode of the compression system will be described below with reference to 
a specific example. 

Firstly, the compactor system analyses all the standard instructions I s and draws up a list 
of all the series of standard instructions existing in the file forming this latter. 

If said file contains 1000 octets, for example, the compactor system launches a search 
procedure on all the series of at least two octets up to a number Q, for example. Said search may 
be run for series of two octets, then three octets and so on up to Q octets. In a preferred 
embodiment, the value of the number Q was 500. 

Consequently, for every sequence of instructions Si, made up of a series of standard 
instructions I s , the compactor system determines whether this sequence Si is already contained in 
the list. If such is the case, the compactor system adds one unit to the number of occurrences Nj 
of said sequence Si. 

By the end of said search process, the compactor system will have generated a complex 
list containing all the instruction sequences Sj examined, each sequence having a number of 
occurrences Nj in the relevant intermediate object code pro gramme pro gram assigned to it. 

An illustrative table is given below for an intermediate object code programme program 
made up of the following series of instructions: 

I-7-3-5-7-3-7-3-5-7. 

Whereas for the purpose of the illustration given in the table, TABLE I below, said series 
of instructions contains ten instructions, each instruction being represented by one octet and 
illustrated by a digit from 1 to 7, the successive sequences of instructions examined comprise 2, 
3, 4 then 5 octets. 
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The successive instruction sequences Si which occur in said intermediate object code 
pro^ramm e proeram a number of times greater than or equal to two, are given in the table below. 

TABLE 1 



4 octets 


[7-3-5-7] :2 






3 octets 


[7-3-5]:2 


[3-5-7] :2 




2 octets 


[7-3]:3 


[3-5]:2 


[5-7] :2 



Secondly, the compactor system replaces certain sequences Si of TABLE I by a code 
denoting specific instructions. 

The code for specific instructions Q is determined chronologically on the basis of the 
first code corresponding to a standard instruction. In a commonplace intermediate object code, 
there are currently 106 standard instructions and the codes for these instructions fall between 000 
and 105. The first specific instruction code Q can then have the value 106, the second value 107 
and so on. Whenever the identical sequences of instructions Sj are replaced by a new specific 
instruction code Cj, once such an operation has been completed, the list illustrated in the table 
above is then re-computed. 

By way of non-restrictive example and in the case where the 4-octet sequence of 
instructions, the sequence 7-3-5-7, shown in the table above is replaced and a corresponding 
code 106 is allocated, the compacted intermediate object code pro gramm eo ro gram becomes: 

1=106-3-106. 

Under these conditions, a sequence of standard instructions I s and specific instructions IS 
existing in identical form at least twice no longer exist. Clearly, the file constituting the 
compressed intermediate object code pro gramm e oro gram FCC and the execution or 
decompression file for this latter are stored at the level of the compactor system mentioned 
above. 
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Once the compacting operation has been performed by the compactor system, there exists 
an intermediate object code pro gramm e pro gram , strictly speaking, which can be executed by the 
target system, and said execution file FEX. The former contains the standard instructions I s and 
the specific instructions IS whilst the latter comprises at least one table allowing the specific 
codes Ci to be linked with the sequences of standard instructions Si replaced by said specific 
codes. Clearly, these two files may be regrouped into one and the same file with a view to 
transferring the latter to the intended target system, i.e. the microprocessor card designed to 
receive it. 

With regard to the execution file FEX, it should be pointed out that it contains at least one 
file, shown by MEM-SEQ, made up of a succession of several fields such as a specific code Ci 
field, a sequence field Si, as outlined above. 

Following said operation, the single file or, as applicable, the two above-mentioned files, 
are transmitted to the target system and processed directly by a loading pro gramm epro gram. This 
loading pro gramm epro gram is mainly responsible for writing the data received to the 
programmable memory 18a or the read only memory 18b so that it can effectively be run 
subsequently. 

As a non-restrictive example, the file relating to the compacted intermediate object code 
pro grammepro eram FCC is stored, without processing, in said programmable memory 18a 
starting at a given address, denoted by ADR-MEM-PGM. 

As for the execution file FEX, the loading pro gramm e pro gram analysanalyses the data of 
this file and dynamically creates a table, denoted by TAB-PRO, enabling the specific instruction 
codes Ci to be associated with the series of instructions. In fact, the table TAB-PRO enables a 
reciprocal match to be made between said specific instruction codes Ci and an embedding 
address which enables the corresponding instructions to be run. 

Figure 2c illustrates the embedding on the one hand of the support File for the compacted 
intermediate object code pro gramm e pro gram FCC, the execution file FEX and the file TAB- 
PRO mentioned above, this latter file having been created by the loading pro gramm e pro gram in 
the programmable memory 18a of the microprocessor card. 



~CHGOl:30353016.vl 



11 



In this drawing, whilst the table of codes for standard instructions I s is stored at the level 
of the interpreter in a table TAB-STD, it is in the programmable memory 18a that the execution 
file FEX and the file TAB-PRO are stored, enabling the address skips to be linked to the 
corresponding specific instruction codes Q, these two tables therefore enabling the compacted 
intermediate object code pro gramm e pro gram FCC to be run effectively at the level of the 
microprocessor of the target unit. An executable unit is therefore provided which can be run by 
the interpreter under conditions that will be explained blow. 

Before moving on to explain how a compacted intermediate object code 
pro eramm e p ro gram FCC is run, a detailed description will be given of the structure of the 
execution files FEX and the file TAB-PRO and the functional relationship between these latter, 
with reference to figures 3a and 3b. 

Figure 3 a provides a detailed illustration of the execution file FEX, which, as explained 
above, has, in addition to the fields for specific codes Ci and instruction sequences Si, a field to 
denote the end of macro-instructions, denoted by FM, indicating the end of said sequence. In a 
preferred although not restrictive embodiment, each specific code Ci may be inserted at the 
beginning of the field, on one octet for example, after which each corresponding sequence Si is 
inserted in a second field of variable length. The end of macro code FM is of the standard type 
and corresponds to that used in the conventional languages mentioned earlier in the description. 

When an execution file FEX is received whose data structure corresponds to that 
illustrated in figure 3a, for example, the different fields Ci, Si and FM are processed separately. 

Firstly, the specific code Ci of the corresponding specific instruction IS is written to the 
file TAB-PRO and the sequence of instructions Si associated with this specific code constituting 
said specific instruction is written to a file or memory denoted by MEM-SEQ from an address 
denoted by ADR-1. This code Ci for the corresponding specific instruction is written to the 
address TAB-PRO + 3x (CODE- 106). In this relation, the address TAB-PRO is specified as 
being the address at which the file TAB-PRO is opened whilst the value CODE represents the 
numerical value of the corresponding code Ci. The operating mode illustrated in figure 3b 
corresponds to an address value TAB-PRO which is arbitrarily set at 0, the first specific code 
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allocated having the value 106 and the following successive specific codes allocated having the 
values 107 and so on. Figure 3b shows only four specific codes 106, 107, 1 10 and 120 in order to 
facilitate understanding, the other memory spaces being filled with arbitrary values. 

Under these conditions, Adr-i is the first available address in the memory MEM-SEQ, 
this address corresponding to the address Adr-1 for the first sequence of instructions Si = Si. 
From this first address, which constitutes the opening of the file in the memory MEM-SEQ, the 
sequences of instructions Si are therefore written in sequence in the order in which they are 
loaded. The end of macro code FM is also written at the end of the corresponding series. 

After said process of writing to the memory MEM-SEQ and after a step to check that the 
writing process has proceeded correctly, the loading Drogramme program writes to the table 
TAB-PRO after each specific code Q the value of the address at which the sequence was written 
in the memory MEM-SEQ. The loading programm e program then re-computes a new write 
address for the next sequence Si of rank i, incremented or decremented depending on the mode 
used to run through said sequences of instructions Si. 

An execution process of a compacted intermediate object code pro gramm e p ro gram 
supported by a file FCC as described above and containing specific instructions will now be 
described with reference to figure 4. 

Such a pro gramme pro gram is run by means of the interpreter with the aid of an 
instruction pointer, denoted by PL In fact, the instruction pointer PI reads the code of the 
instruction to be carried out, standard instruction Is or specific instruction IS, and applies this 
code to the interpreter which then triggers the actions corresponding to it. 

At the start of running a pro gramme pro gram , the instruction pointer PI is loaded with the 
address from which this pro gramme pro gram starts, i.e. the address ADR-MEM-PGM. 

The interpreter analyses the value of the code read by the instruction pointer PL As part 
of this analysis, the latter determines whether this code value corresponds to a standard type code 
Cs or, if not, to a specific code Q. This operation is run from the table TAB-STB stored at the 
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level of the interpreter and by associating the standard instruction codes and hence the standard 
instructions Is with the execution addresses in its programme program . 

If the value of the code read is not in the latter table, the interpreter issues a call to read 
the table TAB-PRO in order to check for the existence of the code value read in the latter table. 
If the code read is no longer in this latter table, the interpreter will be unable to run the 
instruction read and the pro gramm e pro gram run will be halted, prompting an error message, not 
illustrated in the flow chart of figure 4. 

In said figure 4, 2000 denotes the start of the execution operation, 2001 the operation by 
which the instruction pointer PI is initialised on the first pro gramme pro gram instruction and 
2002 an operation whereby the instruction indicated by the instruction pointer PI is read. This 
operation in fact corresponds to the process of reading said code value. 

« In the same manner, at step 2003 in figure 4, a check is run to determine whether the code 
value read in the table belongs or does not belong to the standard codes TAB-STB and whether 
this code value read belongs to the table TAB-PRO, this process in effect forming said test 2003, 
after which a distinction is made as to whether the instruction INS read is a standard instruction 
Is or a specific instruction IS. Fig. 4 does not illustrate the situation in which the code read does 
not belong as explained above and the other of the two tables which generates an error message 
,so as not to overload the drawing. 

If a positive response is received to said test 2003 and the code read corresponds to a 
specific instruction, the instruction pointer PI is computed and stored in the stack so that it can 
then move on to the next instruction. The interpreter reads from the table TAB-PRO the value of 
the address for the sequence of instructions Si associated with the specific code Q read and 
initialises the value of the instruction pointer PI with this value. All of these operations are 
shown under reference 2004 in figure 4. Following said step 2004, the interpreter loops back to 
the step of reading the code, as illustrated in figure 4, by returning to step 2002. 

If a negative response is received to test 2003 and the code read corresponds to an 
instruction of the standard type Is, the interpreter will check in a test step 2005 whether the value 
for this code corresponds to an end of macro value representing an end of sequence. If such is the 
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case, the value previously stored in the stack memory is extracted and the stack is updated, this 
value being loaded into the instruction pointer PL The operation of extracting the value 
previously stored in the stack constituting a return address, followed by an update of the stack, is 
illustrated at 2006, the return address being denoted by ADR-RET. After said step 2006, the 
interpreter loops back to the process at the step where the code value is read, i.e. step 2002. If a 
negative response is received to test 2005 and the value of the code read corresponds to an 
instruction of the standard type but does not correspond to an end of macro or end of series, then 
the code is run by the interpreter in a manner known per se. However, as illustrated in figure 4, a 
test step 2007 is provided in this case prior to actually running said standard instruction. Test 
2007 consists in checking that the value for the code and the corresponding instruction INS does 
not correspond to that for an end o f pro gramm e pro gram . If a positive response is received to said 
test 2007, the execution step 2008 is then run for this instruction by the interpreter, this execution 
step being associated with a step by which the instruction pointer is incremented so that it will 
point to the next instruction. After said step 2008, the interpreter loops back to the step at which 
the code value indicated by the instruction pointer PI is read, i.e. the reading step 2002. 

If a negative response is received to test 2007, in which case the instruction corresponds 
to an end of pro gramm e pro gram instruction, and end step 2009 is run. In this case, the interpreter 
halts its action and hands over to the operating system OS. It then waits for a new command 
instruction. 

The embodiment and method of implementing the process of running a compacted 
intermediate object code pro gramm e pro gram as described with reference to figure 4 is not 
restrictive. 

Firstly, it should be pointed out that the stack memory may be subdivided into two 
separate stack memories, one stack memory for the standard instructions Is and one stack 
memory for the specific instructions IS, alternatively referred to as macro instructions. In an 
embodiment of this type, the maximum number of specific instructions IS interleaved within the 
procedures is known. In order to obtain the total size occupied by this stack, it is sufficient to 
multiply by the maximum number of interleaved procedures. Using a separate stack memory for 
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the specific instructions IS reduces the total memory consumption as compared with using a 
single stack. 

Furthermore, in order to increase the number of specific instructions IS which may be 
used instead and in place of the limited number of specific instructions between 106 and 255, in 
the example described earlier in the description by way of illustration, the specific codes Q can 
advantageously be encoded on two octets. Under these circumstances, a specific code value such 
as the value 255 will then indicate coding on two octets. 

Finally, the target system, if it is an on-board multi-application system, comprises several 
compiled and compacted pro gramm e pro gram s, i.e. several files FCC of the type described 
above. These pro gramm e pro gram s must operate independently. This being the case and there 
being only one interpreter, it runs all the application pro grammep ro gram s loaded by the loading 
pro grammepro gram . If two application pro^ramm e program s use specific instructions, in the 
embodiment explained earlier in the description, it is possible that the compactor system will 
assign the same specific code Q for two series of different instructions. 

In order to remedy such a situation and to enable the interpreter to distinguish between 
the two codes, the fields for the execution file FEX as described above in relation to figure 3a 
may be supplemented by a third parameter relating to an identification number for the 
application in question. This identification number will then also be stored for each assigned 
specific code listed in the table TAB-PRO. This latter parameter is in fact the reference for the 
pro gramm e pro gram loaded at the same time as the file containing the table, allowing each 
specific instruction code Q to be associated with instruction sequences S\ replaced by these latter 
for the application in question. When the interpreter is running the pro gramm e pro gram 
application, it will then be able to single out the specific instructions relating to this application. 

Clearly, the process described above enabling a multi-application on-board system to be 
run has the disadvantage of increased memory consumption because an additional field has to be 
allocated to relate back to the application number in question. 

A more advantageous process will now be described with reference to figure 5. 
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Figure 5 illustrates an on-board system such as a microprocessor card comprising several 
applications, shown by Aj to A k , the values Ai to A k in fact constituting identification numbers 
for each application. To this end, when compacting any source orogramm e program or 
application with a given identification number Ai to A k for example, in accordance with the 
method proposed by the invention as explained earlier in the description, the target system, i.e. 
microprocessor card, transmits the contents of the memory MEM-SEQ along with the 
corresponding specific codes Q to the compactor. In effect, the target system re-computes a file 
of earlier specific coefficients, denoted by F-C-ANT, from the file or table TAB-PRO and the 
contents of the memory MEM-SEQ, relating to the applications Ai to A k _i. The file F-C-ANT 
ensures that each specific code Q is reciprocally matched with the sequence Si associated with it 
for all the applications Ai to A k _i. Under these conditions in a simplified but not restrictive 
embodiment, the file F-C-ANT may consist of a file of the same format as said file FEX. In the 
preferred compacting process illustrated in figure 5, the file F-C-ANT of earlier specific codes is 
then communicated to the compactor in order to teach the latter. 

When compressing a new application with an identification number A k , the compactor 
will look for all occurrences of instruction sequences S\ already registered in the file F-C-ANT, 
i.e. in fact in the table TAB-PRO of the target system for the earlier applications Ai to A k _i. 
Whenever an occurrence is found, the compactor system replaces the corresponding sequence of 
instructions Si with the specific code Q for the corresponding specific instruction IS. Once this 
operation has been completed, the compactor system can then analyse the application bearing 
identification code A k and, of course, look for other occurrences with a view to creating 
additional specific instructions which have not yet been stored. The file F-C-ANT can then be 
updated. The decompression process described with reference to figure 5 may advantageously be 
run in particular as a means of compressing either pro gramm e pro gram s being loaded on the on- 
board system for the first time or pro gramm e pro gram s loaded on the on-board system in addition 
to other existing compacted pro gramm e pro gram s. 

In either of the two cases above, the compacting process proposed by the invention 
consists in storing the execution table relating to at least one compacted intermediate object code 
pro gramme pro gram . the first of these pro gramme pro gram s in the first hypothesis and one or 
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more existing compacted pro gramm e p ro gram s in the second hypothesis, and then reading the 
stored execution table for every additional intermediate pro gramm e pro gram and compressing 
every additional pro gramm e pro gram , taking account of the specific instructions and codes stored 
in the execution table as described earlier in the description. Clearly, the compacted intermediate 
object code pro gramm e pro gram thus created can not be run except on the target system, which 
provided the compactor system with the corresponding relevant file F-C-ANT previously. 

When running the method of compacting an intermediate object code 
programme program . any on-board system such as a multi-application portable object comprising 
a. microprocessor card, for example, and computing resources such as a microprocessor, a 
programmable memory, a read only memory and a language interpreter will have, as in figure 2c 
discussed earlier, at least one set of files stored in the programmable memory 18a for example, in 
addition to the table TAB-STD of standard codes representing an intermediate object code 
programm e program stored at the level of the interpreter. 

Accordingly, the corresponding portable object will have at least one compacted 
intermediate object code programme program . i.e. the file FCC illustrated in figure 2c. This file 
may be made up of an application as described above or may be a function such as a data 
encryption/decryption function or similar. This compacted intermediate object code file will, of 
course, consist of a series of specific instruction codes Q and standard instruction codes 
corresponding to the instruction codes of said intermediate object code programm e program . The 
specific instruction codes Q correspond to sequences of successive standard instructions Si as 
mentioned earlier in the description. 

Furthermore, as illustrated in figure 2c, an execution table allows a reciprocal link to be 
applied between each specific operating code Q and the sequence of successive standard 
instructions S\ associated with this latter. All of these files enable the memory space occupied in 
the memory to be optimised, in particular the programmable memory 18a of the portable object. 

As also illustrated in figure 2c, the execution table has at least one file of successive 
sequences corresponding to the specific instructions, this file being denoted by the memory 
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MEM-SEQ, and a table, denoted by TAB-PRO, of specific instruction codes and addresses at 
which these specific instructions are embedded in the file of successive sequences. 

The compacted intermediate object code p ro gram m epro gram is then run as illustrated in 
figure 4. 

A system for compressing an intermediate object code pro grammepro gram enabling the 
compression method described earlier in the description to be run will now be explained with 
reference to figures 6a and 6b. 

Generally speaking, the compaction method proposed by the invention will be described 
as a combination of modules, these modules being implemented either by hardware means but 
preferably by software means, and the data flows between these modules explained. 

Figure 6a illustrates the compaction system proposed by the invention, which comprises 
at least one module A for analysing all the directly executable instructions constituting the 
intermediate object code pro gramm e pro gram , shown by COD-OBJ-ENT. Generally speaking, the 
computer file supporting the intermediate object code pro gramm e pro gram is regarded as a string 
of octets or character string and the operating mode of the compacting system proposed by this 
invention will be looked at from the point of view of the corresponding processing applied to the 
string. 

Starting with said string of octets, the analysis module A is able to read the object code 
programm e program COD-OB J-INT, single out and establish a list of all the standard instruction 
sequences Sj contained in said pro gramm e pro gram . In figure 6a, the standard instruction 
sequences Si, Sm, Si, Si+i, ... S p , are therefore written in symbolic form in a list in accordance 
with the symbolic notation of the lists. Accordingly, the analysis module A may consist of a 
sliding window corresponding to a number n\ of octets, this sliding window enabling the analysis 
of the sequence Si to be run as mentioned above with reference to table 1 of the description. The 
sliding window, in fact distinguishes between each sequence Si by scrolling the string of octets 
relative to said window. Every time the sequence Si in question occurs, a counting bit BC is 
issued by the analysis module A. 
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As also illustrated in figure 6a, the compaction system proposed by the invention also has 
a module C for counting the number of occurrences in said object code programmeprogram of 
each of the previously mentioned directly executable instruction sequences Si. The counting 
module C may be provided in the form of a software module which counts the number of 
successive bits assigning a value of 1 to said counting bit BC. The counting module C enables 
the corresponding number of occurrences Ni ... Nm, Ni, Nj+i ... N p of each sequence Si ...Sj-i to 
Si+i ... S p and so on to be stored. These can be stored in the form of a list. 

Furthermore, as illustrated in figure 6a, a module AL is provided for allocating to at least 
one sequence of directly executable instructions S\ a specific code C x associated with this 
sequence Si in order to generate a specific instruction, denoted by IS\ in figure 6a, on the basis of 
a criterion whereby the function of at least the corresponding number of occurrences Nj is higher 
than a reference value as mentioned earlier in the description. 

If the function of at least the number Ni is higher than the function value of the above- 
mentioned reference value, the module AL will issue a compaction command COM-COMP 
which may consist of one bit with a corresponding value 1 or 0. 

Finally, the compaction system proposed by the invention has a compacting module 
strictly speaking, COMP, which receives on the one hand the file relating to said intermediate 
object code programme program COD-OBJ-INT and the counting command COM-COMP. The 
compacting module strictly speaking COMP in effect enables every occurrence of every 
sequence Sj in said intermediate object code programm e program . considered as a string of octets, 
corresponding to a specific instruction IS, to be replaced by the specific code Q associated with 
this sequence of instructions. 

As regards the operating mode of the compacting module COMP as such, it should be 
pointed out that it may have a reading sub-module which uses a sliding window, similar to that 
of the analysis module, enabling the sequence of standard instructions Si in said string of octets 
to be located. In practice, when said sequence of standard instructions Si is located, as illustrated 
in figure 6a, the compacting module may have a left-hand partitioning and a right-hand 
partitioning sub-module for the sequence Si in question in order to generate a left string, denoted 
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by LS, and a right string, denoted by RS. It may then have a concatenation module which uses 
the specific code Q constituting the specific instruction ISi, so that the corresponding specific 
code Cj } considered as a string of octets, can be concatenated on the one hand, with the left chain 
LS for example, after which the unit thus formed is concatenated with the right chain RS, which 
ensures that the sequence Si will be replaced by the specific code Q. The compacting module 
strictly speaking COMP thus issues a compacted intermediate object code pro ^ramm e pro gram 
denoted by COD-OBJ-INT-COMP in figure 6a. Clearly, the compaction system illustrated in 
figure 6a enables the compaction process described above to be applied to the set of all the 
directly executable instruction sequences Si in question. 

In one embodiment which is not restrictive, the allocation module AL may, as illustrated 
in figure 6b, have a module for computing the number of octets from the length ni of the 
instruction sequence Si, this module being denoted by ALi in figure 6b. It may also have a 
computing module, shown by AL 2 , to form the product of this length n x and the number of 
occurrences H of this sequence Sj of standard instructions. This product, written Pi, is 
representative of the compression gain for the sequence of directly executable instructions Si 
considered. 

Furthermore, the allocation module AL may have a module, denoted by AL3, for 
comparing this product Pj with a given threshold value, S. The threshold value S may be 
determined experimentally. It may also be established on the basis of this experimental value in 
such a way that, for an intermediate object code pro gramm eprogram of a given length, it 
corresponds to a given percentage of this length. 

If a negative response comes back from the comparison test run by the module AL3, the 
rank i of each directly executable sequence of instructions Si is incremented by one unit and the 
new value of i is sent back to the analysis module A on the one hand and the counting module C 
on the other. 

If a positive response comes back from the comparison test run by the module AL3, a 
module AL4 will establish a corresponding specific code Q and, finally, a module AL5 will apply 
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a reciprocal link so as to write the specific code Q and the relevant sequence of directly 
executable instructions Si to constitute the specific instruction ISi. 

The module AL4 may be a compression software module enabling an initial value, for 
example the value 106 mentioned earlier in the description, to be used as a basis for allocating a 
corresponding value to the relevant corresponding sequence of instructions Sj. Each specific 
instruction ISj may then be written in the form of a corresponding list. 

Real-time compression tests on the pro grammepro grams or applications contained in the 
microprocessor cards sold by BULL CP8 in France have shown that a compression gain of more 
than 33% can be obtained, which, when applying the compaction process to three applications on 
a mobile portable object, essentially represents a gain of one additional application for this type 
of object. 

This compression gain was obtained under substantially normal conditions of usage by 
the user whilst the slowing-down caused by calling up macro instructions is not substantially 
more than 10% of the running time if no macro instructions are included, this slowing-down 
being inherent in successively calling up reading operations at the level of the table TAB-B-PRO 
and the file MEM-SEQ. 
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ABSTRACT OF THE DISCLOSURE 

The invention concerns a data compaction method and system for an intermediate 
pro gram. The method consists in: searchm&jhe program (1000) for identical sequences (Si) and 
counting Ni number of occurrences of ea ch seque nce (Si): a comparison test (100 1) to find the 
su periority of a function f(Ni) to a reference value enables to gen erate (1003) a specific 
instruction of a spe cific code (Ci) with which the s equence (Si) is asso ciated; replacing (1004) 
each occurrence in the seque nce (Si) bv the spe cific code (Ci) in the intermediate prog ram to 
create a compacted intermediate program (FCC) with which an executing file (FEX) is 
associated. The invention is applicable to multiple application portable objects such as 
microprocessor cards, onboard systems or the like. 
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